Asymmetric encryption for end-to-end e-mail encryption is well known in the prior art. Pretty Good Privacy also known as Phil's good program, called PGP, by PGP Corporation, Palo Alto Calif., and its open source follow-up effort GnuPG are one example. Similarly, the OSI standards family has come forth with x509 or S/MIME.
In these technologies, there are many approaches for establishing a trust or security hierarchy with all its ramifications. The pure “web-of-trust” approach is pioneered by GPG/PGP.
The S/MIME family of standards puts significant effort in managing keys and trust by a cascade of central institutions, such as Certification Authorities (CAs) and Registration Authorities (RAs), and in revocation, which are all summarized under the term “public key infrastructure” (PKI).
To date, except for very specific business relationships or inside large corporations, PKIs have not met broad user and consumer acceptance. This is due to several reasons:
Difficulties with liabilities and governance of CAs; Government institutions are reluctant to certify for data protection and privacy concerns and liability reasons as well;
Long and cumbersome processes are needed for obtaining a key and the human factor has not sufficiently been considered such as convenience during usage of such systems etc.
One approach to exchange messages that only relied on certificates for HTTPS web access is the now defunct “UPS Secure Online Courier” from United Parcel Service Inc. Similar services have been offered by various other companies such as Tumbleweed, Zixit, and CertifiedMail (see patent references below). While correct in their intent, these solutions had several points which could be improved, typically:                non-messaging users cannot respond;        downloads and installation of software are required;        some solutions also resort to self-decrypting archives that are a serious problem for anti-virus filters and off-line key guessing attacks;        initial passwords are sent in e-mails upon registration;        no out-of-band channel is supported for alternate sender/recipient verification;        management of private keys is often delegated to a central service (e.g. crypto-proxy or boundary/gateway server)—thus violating the rule that private keys are never shared;        costly special purpose servers must be run centrally by the mail domain providing institution;        lack of integration with the above state-of-the art end-to-end message security standards (due to proprietary approaches);        possession of private keys by end users is a precondition for the system to work at all;        it is necessary to obtain yet another e-mail address and traffic analysis is not prevented, so that an attacker can passively collect complete header information on each sent message.        
In US 2002/0007453 (“Secure Electronic Mail System and Method”) solutions to the above-mentioned problems are proposed; however, many of the above-stated requirements are not addressed because according to US 2002/0007453 the sender is required to have a private key and sender-side special purpose software.
According to U.S. Pat. No. 6,424,718 (“Data communications system using public key cryptography in a web environment”) multiple private keys are stored on a server whereas the private keys are shared among users. U.S. Pat. No. 6,424,718 also requires the download of applet code to the client from the server.
According to US 2003/0007645 (“Method and system for allowing a sender to send an encrypted message to a recipient from any data terminal”) a tunnel is built to a server hosting recipient public keys and the sender's private key. However, the latter appears to be a significant disadvantage because private keys are not to be entrusted to anybody.
WO 01/97089 A1 (“Secure Forwarding System”, by Zixit) describes fundamental mechanisms for secure email delivery, however, beyond the very basic scenario it fails to address the issues of out-of-band authentication and the trust relations derivable there from.
U.S. Pat. No. 6,529,956 (“Private, trackable URLs for directed document delivery”) and U.S. Pat. No. 6,516,411 (“Method and apparatus for effecting secure document format conversion”) assigned to Tumbleweed address the basic mechanisms of one-time URLs for secure message delivery and recipient-determined format presentation beyond transmission security. No provisions are taken to address the implications of for example a forgotten password or other lost authenticator of an involved party.
U.S. Pat. No. 6,684,248 (“Method of transferring data from a sender to a recipient during which a unique account for the recipient is automatically created if the account does not previously exist”, certifiedmail.com) presents a mechanism to securely deliver a message from a messaging user to a communication partner that is not yet a messaging user. By granting access on a “per account” basis instead of “per sender” basis, it fails to appropriately address the needs different senders and may lead to inadvertent information leaking e.g. due to typos in a submitted e-mail address.